[internal] Add experimental_compatible_resolves to python_requirement and use it to generate lockfiles
#13978
Conversation
…ent` and use it to generate lockfiles # Rust tests and lints will be skipped. Delete if not intended. [ci skip-rust] # Building wheels and fs_util will be skipped. Delete if not intended. [ci skip-build-wheels]
# Rust tests and lints will be skipped. Delete if not intended. [ci skip-rust] # Building wheels and fs_util will be skipped. Delete if not intended. [ci skip-build-wheels]
Given this, should we instead continue to calculate the resolve based on who is depending on each requirement, and only use the |
|
I recommend that we either:
Imo the status quo is too confusing to try to preserve - don't attempt to handle mixed interpreter constraints with multiple resolves until we've properly designed it. Given that this is all feature gated and collaboration is mostly async with the holidays, I'd vote for punting, but understand if we want to block. Wdyt? |
Part of the design from #13621. This change has worked well for JVM.
This does have an open question though of how we should determine which interpreter constraints to use for each resolve.
python_requirementtargets do not have constraints themselves, so we either need to associate each resolve with particular constraints via global config, or we need to look at all consumers of the resolves to calculate it. For now, we just use the global default.Reminder that these changes are only enabled if you use
--python-enable-resolves.[ci skip-rust]
[ci skip-build-wheels]